perm filename WADLER[W76,JMC] blob sn#207606 filedate 1976-03-19 generic text, type C, neo UTF8
COMMENT āŠ—   VALID 00002 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	Comments on your paper
C00005 ENDMK
CāŠ—;
Comments on your paper

Side effects are generally considered worse than go to's,
and the objections arose earlier.  The first objections
to side effects came when it was discovered that they
constrained compilers to produce inefficient code in
order to preserve possile side effects.  The second
objection was the mathematical objection.  Your first
objection, the small mind of the programmer, came last
along with structured programming.

The example of cons is a good one.  Yu should try to
see what mathematical property causes the side-effects
to disappear and cons to act as a mathematical function.
If we can get some general sufficient conditions under
which the side-effects will disappear at a higher level,
people can try to construct programs that have this
property.

I have two other examples.  The first is my compilers
LCOM0 and LCOM4 which are pure functions except for their
use of GENSYM which gives a new value each time it is
called.  You might try to see what would be involved in
eleminating GENSYM from LCOM0.  The second is a game
tree search program in which update and revert functions
are used so that only one copy of the board is carried.
The side-effects of this become invisible, so this is
another example you should consider.

Let me recommend that you do a research project this
Spring on these topics.

The reason I consider eliminating side effects difficult
is examples like

f(g(x)+h(x))

where the evaluation of g modifies x.

In general, I think your paper raises some interesting
questions, but you don't have any substantial results,
and purely propagandist papers are not of much use.